Methods And Apparatus For Authenticating Components Of Processing Systems

ABSTRACT

When a processing system boots, it may retrieve an encrypted version of a cryptographic key from nonvolatile memory to a processing unit, which may decrypt the cryptographic key. The processing system may also retrieve a predetermined authentication code for software of the processing system, and the processing system may use the cryptographic key to compute a current authentication code for the software. The processing system may then determine whether the software should be trusted, by comparing the predetermined authentication code with the current authentication code. In various embodiments, the processing unit may use a key stored in nonvolatile storage of the processing unit to decrypt the encrypted version of the cryptographic key, a hashed message authentication code (HMAC) may be used as the authentication code, and/or the software to be authenticated may be boot firmware, a virtual machine monitor (VMM), or other software. Other embodiments are described and claimed.

This application is a continuation of U.S. patent application Ser. No.11/648,511, filed Dec. 29, 2006, the content of which is herebyincorporated by reference.

FIELD OF THE INVENTION

The present disclosure relates generally to the field of dataprocessing, and more particularly to methods and related apparatus forauthenticating components of processing systems.

BACKGROUND

A processing system may include hardware resources, such as a centralprocessing unit (CPU), random access memory (RAM), and nonvolatilememory. The processing system may also include software resources, suchas a basic input/output system (BIOS), a virtual machine monitor (VMM),and one or more guest operating systems (OSs) running on the VMM. Whenthe computer system is started or reset, it may load the BIOS, and thenthe VMM. The VMM may then create one or more virtual machines, and thevirtual machines may boot to different OSs or to different instances ofthe same OS.

In addition to RAM and one or more CPUs, a processing system may includea security coprocessor, such as a trusted platform module (TPM). A TPMis a hardware component that resides within a processing system andprovides various facilities and services for enhancing the security ofthe processing system. For example, a TPM may be implemented as anintegrated circuit (IC) or semiconductor chip, and it may be used toprotect data and to attest to the configuration of a platform. A TPM maybe implemented in accordance with specifications such as the TrustedComputing Group (TCG) TPM Specification Version 1.2, dated Oct. 2, 2003(hereinafter the “TPM specification”), which includes parts such asDesign Principles, Structures of the TPM, and TPM Commands. The TPMspecification is published by the TCG and is available from the Internetat www.trustedcomputinggroup.org/home.

The sub-components of a TPM may include an execution engine and securenonvolatile (NV) memory or storage. The secure NV memory is used tostore sensitive information, such as encryption keys, and the executionengine protects the sensitive information according to the securitypolicies dictated by the TPM's control logic.

In general, a TCG-compliant TPM provides security services such asattesting to the identity and/or integrity of the platform, based oncharacteristics of the platform. The platform characteristics typicallyconsidered by a TPM include hardware components of the platform, such asthe processor(s) and chipset, as well as the software residing in theplatform, such as the firmware and OS. A TPM may also support auditingand logging of software processes, as well as verification of platformboot integrity, file integrity, and software licensing. A TPM maytherefore be considered a root of trust for a platform. However, the TPMtypically also relies on certain code that is executed by the platform'sCPU to be inherently reliable. That code is known as the core root oftrust for measurement (CRTM).

Specifically, the TCG recognizes three primary roots of trust for aplatform: the root of trust for storage (RTS), the root of trust forreporting (RTR), and the root of trust for measurement (RTM). Asexplained in the TCG glossary athttps://www.trustedcomputinggroup.org/groups/glossary, the TPM typicallyserves as the RTS and RTR. By contrast, the RTM is typically “the normalplatform computing engine, controlled by the CRTM. This is the root ofthe chain of transitive trust.” Moreover, the TCG glossary explains thata root of trust is a “component that must always behave in the expectedmanner, because its misbehavior cannot be detected.”

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present invention will become apparentfrom the appended claims, the following detailed description of one ormore example embodiments, and the corresponding figures, in which:

FIG. 1 is a block diagram depicting a suitable data processing system inwhich certain aspects of an example embodiment of the present inventionmay be implemented;

FIG. 2 is a block diagram depicting an example data processingenvironment involving the data processing system of FIG. 1;

FIG. 3 is a flowchart of a process for provisioning the processingsystem of FIG. 1 with a third-party key and various manifests, accordingto an example embodiment of the present invention;

FIG. 4 is a block diagram of an augmented authenticated code module,according to an example embodiment of the present invention;

FIG. 5 is a flowchart of a process for establishing a protectedcommunication channel between a processing unit and a securitycoprocessor, according to an example embodiment of the presentinvention; and

FIG. 6 is a flowchart of a process for authenticating components of thedata processing system of FIG. 1, according to an example embodiment ofthe present invention.

DETAILED DESCRIPTION

An embodiment of the present invention provides for authenticatingplatform components such as boot firmware and/or VMM code, thusproviding enhanced security, relative to platforms that rely on suchcode to be inherently reliable. For instance, the platform may check theauthenticity of the boot firmware in a system read-only memory (ROM).Alternatively, the code to be authenticated may include components suchas an OS and/or a VMM from a hard disk or other mass storage device.

As background, in a platform with a TPM, platform measurements andencryption can be used to seal sensitive information or secrets to theTPM. For instance, in a processing system with a VMM, secrets can besealed to the TPM using measurements of the VMM and other platformcomponents. The TPM may prevent the secrets from subsequently beingreleased or unsealed from the TPM unless VMM and other platformmeasurements are verified to match the measurements used for sealing.However, when a secret is unsealed, it may be communicated in plain text(i.e., not encrypted) over a communication channel in the processingsystem between the TPM and the CPU.

The present disclosure describes mechanisms and processes forcommunicating secrets between a security coprocessor (e.g., a TPM) and aprocessing unit (e.g., a CPU) in an encrypted format. Consequently, evenif an attacker were to snoop the internal buses in the processingsystem, the attacker would not be able to intercept plain text secrets.

The described mechanisms and processes may be suitable for providingenhanced protection for high value content, with regard to digitalrights management (DRM), for example. As described in greater detailbelow, in one embodiment, the data on the communication channel betweenthe TPM and the CPU is encrypted using per-session cryptographic keys.In addition, the CPU and the TPM are provisioned in advance with acryptographic key (referred to herein as a “third-party key” or “3PK”)to be used for authenticating the session end points and creating theper-session cryptographic keys. The 3PK may therefore also be referredto as an authentication key.

For purposes of this disclosure, with regard to processing units andwith regard to processing systems that include processing units, a“first party” is the manufacturer of the processor, and a “third party”is any other entity associated with the processing unit or processingsystem. For instance, manufacturers of processing systems and owners ofprocessing systems are considered “third parties.”

Referring again to the third-party key, the manufacturer of the CPU neednot load the 3PK into the CPU or the TPM. Indeed, since the TPM isassociated with the platform, if the CPU manufacturer does not alsoassemble platforms, the CPU manufacturer may have no opportunity to loadthe 3PK into the TPM. Instead, the 3PK, and the process for loading itinto a processing system, can be controlled primarily by some otherparty, such as the manufacturer of the processing system. For example,as described in greater detail below, when building a processing system,an original equipment manufacturer (OEM) may obtain an augmentedauthentication code (AC) module that contains the third-partycryptographic key to be installed in the CPU of that processing system.As described in greater detail below, within the augmented AC module,the 3PK may be protected by encryption, based on a processing unit key(PUK). For purposes of this disclosure, a processing unit key or PUK isa cryptographic key that is stored in a processor when the processor ismanufactured, and that remains in the processor in nonvolatile form. Forinstance, the processor may retain the key despite a power cycle orreset of the processor. The augmented AC module may also includepreliminary boot code, and the augmented AC module may be protected witha signature.

The augmented AC module may be stored in boot storage (e.g., flashmemory that typically contains the BIOS code). The platform builder mayalso install the 3PK into the TPM of the platform during platformmanufacturing. Subsequently, on reset, the CPU may locate and run thepreliminary boot code in the augmented AC module. Accordingly, ACmodules, and similar types of modules, that have been augmented with anencrypted 3PK may be considered augmented boot code modules. In oneembodiment, the CPU may use a firmware interface table (FIT) as astandard mechanism to locate and run the augmented AC module. Additionalinformation about FITs is provided in the Intel® Itanium® ProcessorFamily System Abstraction Layer Specification, dated December 2003,which may be obtained from the Internet atdownload.intel.com/design/Itanium/Downloads/24535907.pdf. When run, theaugmented AC module may install the 3PK to CPU registers that are onlymodifiable by privileged code. Thus, a platform may use the methodologydescribed herein to carry OEM keys in BIOS memory and securely installthem into the processor at each boot.

An augmented AC module may also initialize the TPM and create a sessionkey that will be used by the processor and TPM to encrypt data exchangedbetween the two components. For example, once 3PKs have been installedinto the processor and the TPM, those keys can in turn be used togenerate one or more session keys, using standard cryptographic schemes.The session is then used to secure communications between the processorand the TPM.

The described solution allows secure communication between a CPU and asecurity processor such as a TPM, thus ensuring secure exchange, evenagainst an attacker with sophisticated snooping hardware and physicalaccess to the machine. For instance, a platform according to the presentdisclosure may ensure that cryptographic keys used for protecting thedata content (e.g., a key for protecting a Moving Picture Experts Group(MPEG) movie, a key for protecting a database of credit cardinformation, etc.) are protected from in-target probe (ITP) basedattacks.

In addition, the present disclosure describes a convenient, flexible wayto provision a platform with keys for establishing a protectedcommunication channel. A key may be selected by a third party andinstalled into a platform by that third party. The 3PK key need not bebuilt in to the processor. The processor manufacturer therefore need notknow the 3PK. In addition, should a processor be returned to themanufacturer, the processor may be reused without compromising the 3PK.A 3PK may be changed if needed by a trusted agent, and a 3PK may be tiedto the processor only when the processor is present in a platform.Accordingly, such a 3PK may also be referred to as a platform key.

An OEM or other entity may also use the 3PK to create manifests forvarious software components of the processing system when assembling orconfiguring the processing system. The processing system maysubsequently use the 3PK from the augmented AC module to authenticatethose components, for example during boot. The processing system maythus avoid executing software components that have been infected withmalware such as viruses, rootkits, virtual machine rootkits, etc. Forinstance, as described in greater detail below, the OEM may save afirmware manifest with an authentication code for the system firmware inthe boot flash memory. When the processing system subsequently boots,before executing the firmware, the system may check the manifest todetermine whether the firmware has been tampered with. Similar steps maybe taken to protect other components, such as a VMM, an OS, etc.

Alternatively, the OEM may store more than one of these 3PKs in theaugmented AC module, with each 3PK used for a different purpose. Forinstance, one 3PK may be used for establishing secure communicationsbetween the processor and the TPM, and other 3PKs may be used for (a)authenticating the platform firmware, (b) authenticating a host OS, and(c) authenticating a VMM.

FIG. 1 is a block diagram depicting a suitable data processing system 20in which certain aspects of an example embodiment of the presentinvention may be implemented. Data processing system 20 has varioushardware components 82, such as a central processing unit (CPU) 22,communicatively coupled to various other components via one or moresystem buses 24 or other communication pathways or mediums. Thisdisclosure uses the term “bus” to refer to shared communicationpathways, as well as point-to-point pathways. CPU 22 may include two ormore processing units, such as processing unit 30 and processing unit32. Alternatively, a processing system may include a CPU with oneprocessing unit, or multiple processors, each having at least oneprocessing unit. The processing units may be implemented as processingcores, as Hyper-Threading (HT) technology, or as any other suitabletechnology for executing multiple threads simultaneously orsubstantially simultaneously.

As used herein, the terms “processing system” and “data processingsystem” are intended to broadly encompass a single machine, or a systemof communicatively coupled machines or devices operating together.Example processing systems include, without limitation, distributedcomputing systems, supercomputers, high-performance computing systems,computing clusters, mainframe computers, mini-computers, client-serversystems, personal computers, workstations, servers, portable computers,laptop computers, tablets, telephones, personal digital assistants(PDAs), handheld devices, entertainment devices such as audio and/orvideo devices, and other devices for processing or transmittinginformation.

Processing system 20 may be controlled, at least in part, by input fromconventional input devices, such as a keyboard, a mouse, etc., and/or bydirectives received from another machine, biometric feedback, or otherinput sources or signals. Processing system 20 may utilize one or moreconnections to one or more remote data processing systems, such asthrough a network interface controller (NIC) 40, a modem, or othercommunication ports or couplings. Processing systems may beinterconnected by way of a physical and/or logical network, such as alocal area network (LAN), a wide area network (WAN), an intranet, theInternet, etc. Communications involving the network may utilize variouswired and/or wireless short range or long range carriers and protocols,including radio frequency (RF), satellite, microwave, Institute ofElectrical and Electronics Engineers (IEEE) 802.11, 802.16, 802.20,Bluetooth, optical, infrared, cable, laser, etc. Protocols for 802.11may also be referred to as wireless fidelity (WiFi) protocols. Protocolsfor 802.16 may also be referred to as WiMAX or wireless metropolitanarea network protocols, and information concerning those protocols iscurrently available at grouper.ieee.org/groups/802/16/published.html.

FIG. 2 is a block diagram depicting an example data processingenvironment 12 involving processing system 20 from FIG. 1. Inparticular, data processing environment 12 includes processing system 20as a local processing system, and a remote processing system referred toas an augmented authenticated code module (AACM) generator 80.Processing system 20 and AACM generator 80 may communicate via a network90. For instance, processing system 20 may be located in an OEM assemblyplant 102, and when the OEM is assembling or configuring processingsystem 20, the OEM may cause processing system 20 to communicate withAACM generator 80 to provision processing system 20 with one or more3PKs specific to that OEM, as described in greater detail below withregard to FIG. 3. In particular, as described below, the OEM may causeAACM generator 80 to embed 3PK 72, 3PK′ 75, and 3PK″ 77 in thepreliminary AC module, thereby converting it into an AACM specific tothat OEM.

Referring again to FIG. 1, within processing system 20, processor 22 maybe communicatively coupled to one or more volatile or nonvolatile datastorage devices, such as RAM 26, read-only memory (ROM) 42, mass storagedevices 36 such as hard drives, and/or other devices or media, such asfloppy disks, optical storage, tapes, flash memory, memory sticks,digital video disks, etc. For purposes of this disclosure, the term“ROM” may be used in general to refer to nonvolatile memory devices suchas erasable programmable ROM (EPROM), electrically erasable programmableROM (EEPROM), flash ROM, flash memory, etc. Processor 22 may also becommunicatively coupled to additional components, such as a videocontroller, integrated drive electronics (IDE) controllers, smallcomputer system interface (SCSI) controllers, universal serial bus (USB)controllers, input/output (I/O) ports, input devices, output devicessuch as a display, etc.

In the embodiment of FIG. 1, processing system 20 also includes a TPM44. In other embodiments, other types of security coprocessors may beused. Processor 22, RAM 26, TPM 44, and other components may beconnected to a chipset 34. Chipset 34 may include one or more bridges orhubs for communicatively coupling system components, as well as otherlogic and storage components.

Some components, such as the video controller for example, may beimplemented as adapter cards with interfaces (e.g., a PCI connector) forcommunicating with a bus. In one embodiment, one or more devices may beimplemented as embedded controllers, using components such asprogrammable or non-programmable logic devices or arrays,application-specific integrated circuits (ASICs), embedded computers,smart cards, and the like.

The invention may be described herein with reference to data such asinstructions, functions, procedures, data structures, applicationprograms, configuration settings, etc. When the data is accessed by amachine, the machine may respond by performing tasks, defining abstractdata types or low-level hardware contexts, and/or performing otheroperations, as described in greater detail below. The data may be storedin volatile and/or nonvolatile data storage. For purposes of thisdisclosure, the term “program” covers a broad range of softwarecomponents and constructs, including applications, drivers, processes,routines, methods, modules, and subprograms. The term “program” can beused to refer to a complete compilation unit (i.e., a set ofinstructions that can be compiled independently), a collection ofcompilation units, or a portion of a compilation unit. Thus, the term“program” may be used to refer to any collection of instructions which,when executed by a processing system, perform a desired operation oroperations. The programs in processing system 20 may be consideredcomponents of a software environment 84.

For instance, when processing system 20 boots, a BIOS 50 and a VMM 52may be loaded into RAM 26 and executed within software environment 84.VMM 52 may include components which more or less serve as an OS, or itmay run on top of a host OS 54. BIOS 50 may be implemented in accordancewith Version 2.0 of the Unified Extensible Firmware InterfaceSpecification, dated Jan. 31, 2006, for instance. ROM 42 may alsoinclude modules such as an augmented AC module (AACM) 60. As describedin greater detail below with regard to FIG. 6, AACM 60 may causeprocessing system 20 to authenticate BIOS 50, OS 54, and/or VMM 52before allowing them to run.

FIG. 3 is a flowchart of a process for provisioning processing system 20with 3PKs, according to an example embodiment of the present invention.The illustrated process pertains to assembly or configuration operationsmanaged by an OEM, beginning after the OEM has selected processingsystem 20 to be provisioned with a 3PK. At block 110, the OEM selectsthe 3PKs to be provisioned.

At block 112, the OEM prepares a preliminary AC module. In the exampleembodiment, the OEM uses a format such as the one described in theLaGrande Technology Preliminary Architecture Specification, datedSeptember 2006 (hereinafter “the LTPA Specification”), for the ACmodule. The LTPA Specification is currently available from the Internetat www.intel.com/technology/security/downloads/LT_spec_(—)0906.pdf.

The example processing system of FIG. 1 provides launch and controlinterfaces using functions known as safer mode extensions (SMX).Additional information concerning SMX may be obtained from the LTPASpecification. The LTPA Specification also describes how an AC modulecan be authenticated and executed. For example, pages 11 and 12 providethe following explanations:

-   -   To support the establishment of a protected environment, SMX        enables the capability of an authenticated code execution mode.        This provides the ability for a special code module, referred to        as the authenticated code module (AC module), to be loaded into        internal RAM (referred to as authenticated code execution area)        within the processor. The AC module is first authenticated and        then executed using a tamper resistant method.    -   Authentication is achieved through the use of a digital        signature in the header of the AC module. The processor        calculates a hash of the AC module and uses the result to        validate the signature. Using SMX, a processor will only        initialize processor state or execute the AC code module if it        passes authentication. Since the authenticated code module is        held within internal RAM of the processor, execution of the        module can occur in isolation with respect to the contents of        external memory or activities on the external processor bus.

Referring again to block 112, to prepare the preliminary AC module, theOEM may load user code/data into the user area of the preliminary ACmodule. Here, the preliminary AC module serves as a formatted input ofOEM content that needs to be embedded in the augmented AC module. In theexample embodiment, the code in the user area includes instructions anddata to control the preliminary boot operations before control is givento BIOS 50. Processing system 20 may also populate other portions of thepreliminary AC module, such as the size field, for instance.

As shown at block 114, processing system 20 may then connect to AACMgenerator 80. In the example embodiment, processing system 20 and AACMgenerator 80 establish a secure channel to communicate encrypted data.Any suitable technique may be used to establish that secure channel. Asshown at block 116, processing system 20 may then send a message orrequest 84 to AACM generator 80. As shown in FIG. 2, request 84 mayinclude the preliminary AC module, as well as the desired 3PKs. In theexample embodiment, the preliminary AC module will contain a field thatthe OEM or third-party manufacturer populates to indicate the processorfamily for which the AACM is sought. As shown at blocks 120 and 122,AACM generator 80 may receive the preliminary AC module and the 3PKsfrom processing system 20, and may then encrypt the 3PKs.

In the embodiment of FIG. 2, AACM generator 80 is managed by themanufacturer of processor 22, and AACM generator 80 uses a predeterminedprocessor manufacture key (PMK) 71 to encrypt the 3PKs. In theembodiment of FIG. 2, PMK 71 is a private key, and processing unit 30includes a PUK 70 that is the corresponding public key. In anotherembodiment, the PMK and the PUK may be the same key (i.e., they may havethe same value).

In the embodiment of FIG. 1, PUK 70 may be permanently burned intoprocessing unit 30 by the manufacturer of processor 22 during themanufacturing process, before processor 22 is shipped to a purchasersuch as an OEM. The manufacturer of processor 22 may keep PMK 71 secret,such that no other entity ever learns the value of PMK 71.Alternatively, the processor manufacturer may arrange for a separatetrusted entity to manage AACM generator 80. Although PUK 70 may beconsidered a “public” key, it may also be kept secret, such that itsvalue is never released by processing unit 30.

Referring again to FIG. 3, AACM generator 80 then builds an AACM 60 thatincludes the encrypted 3PKs, as shown at block 124. For example,referring back to FIG. 1, AACM generator 80 may include the following3PKs in AACM 60: encrypted 3PK (E3PK) 72A, E3PK′ 75A, and E3PK″ 77A. Inparticular, referring again to FIG. 2, when AACM generator 80 buildsAACM 60, AACM generator 80 may append the E3PKs to the user data of thepreliminary AC module and update the module size field. Alternatively,AACM 60 may include one or more predefined fields for holding encrypted3PKs. An AACM that includes an encrypted version of a 3PK may also bereferred to as an encrypted AC module.

FIG. 4 is a block diagram of AACM 60 from FIG. 1, showing a moduleheader, which is followed by a scratch area, followed by a user areawith the encrypted 3PKs appended at or near the end of the module,following the user code/data from the preliminary AC module.Alternatively, an AC module may be structured with one or moreindependent fields to hold encrypted 3PKs, possibly in the module'sheader. The instructions and other data in the use area, which are usedto control the preliminary boot operations, are referred to herein asAACM code 79.

Referring again to FIG. 3, AACM generator 80 then sends AACM 60 toprocessing system 20, as shown at block 126. Processing system 20 mayreceive AACM 60 from AACM generator 80 at block 130. Processing system20 may then sign AACM 60, as indicated at block 132. For example, theOEM may select an AC module key pair, such as a Rivest, Shamir, Adelman(RSA) public/private key pair, and may then load the public key fromthat pair into the header of AACM 60. The OEM may use the private keyfrom that pair to generate an RSA signature for AACM 60, possibly basedon a hash of the user area and possibly other portions of AACM 60. TheOEM may then store that RSA signature in the header of AACM 60.Referring again to FIG. 4, such an RSA public key 76 and such an RSAsignature 78 are depicted in the header of AACM 60.

Thus, the OEM (or other third party) may select the 3PKs as well as theRSA public key for the AC module. Consequently, to distinguish betweenthose keys, the RSA public key may be referred to as the primary modulekey, and the 3PKs may be referred to as supplemental module keys.

As shown at block 134, processing system 20 may then store AACM 60 inROM 42, as depicted in FIG. 1. In the embodiment of FIG. 1, processingunit 30 is configured to serve as a bootstrap processor (BSP), andprocessing system 20 is configured to use ROM 42 as the boot storage(i.e., the nonvolatile storage from which processing unit 30 obtainsinstructions for initializing and configuring processing system 20 atpower up or reset).

Thus, an OEM or other entity performing system configuration may installcryptographic keys such as E3PK 72A into the system ROM (e.g., ROM 42).Furthermore, since E3PK 72A is itself encrypted, even if an attackerwere able to extract E3PK 72A from ROM 42, the attacker still would notbe able to decrypt and use E3PK 72A.

As shown at block 136 of FIG. 3, processing system 20 may then save oneor more of the 3PKs (e.g., 3PK 72) into TPM 44. For instance, processingsystem 20 may securely install 3PK 72 and the other 3PKs into TPM 44during each boot. Alternatively, the OEM could provision 3PK 72 and theother 3PKs into TPM 44 during processing system manufacturing.

Processing system 20 may then use one or more of the 3PKs to computeauthentication codes for various software components to be protected,and processing system 20 may save those authentication codes asmanifests in processing system 20. In the example embodiment, a hashedmessage authentication code (HMAC) is used for each authentication codeor manifest. The HMACs may have the form

HMAC_(K)(m)=h((K xor opad)∥h((K xor IPAD)∥m))

where m is the message or data to be protected, h is the hashingfunction, K is the selected 3PK (e.g., 3PK′ 75), ipad is a predefinedinner pad constant, and opad is a predefined outer pad constant.Additional information concerning HMACs is currently available from theInternet at http://en.wikipedia.org/wiki/HMAC.

For example, as depicted at block 140, processing system 20 may computean HMAC for the system firmware of processing system 20. In particular,processing system 20 may use 3PK′ 75 as K for the HMAC, and processingsystem 20 may use the firmware image (e.g., the contents of BIOS 50) asm for the HMAC. Similarly, as shown at blocks 142 and 144, processingsystem 20 may use 3PK″ 77 to compute an HMAC for VMM 52, and processingsystem may use another 3PK to compute an HMAC for OS 54.

As indicated at block 150, processing system 20 may then save the HMACsas manifests for the corresponding components. For instance, as shown inFIG. 1, processing system 20 may append, prepend, or otherwise add a VMMauthentication code (AC) 53 to VMM 52, a firmware AC 51 to BIOS 50, andan OS AC 55 to OS 54. Alternatively, manifests or authentication codesmay be saved separately from the corresponding software modules.

FIG. 5 is a flowchart of a process for establishing a protectedcommunication channel between a processing unit and a TPM according toan example embodiment of the present invention. FIG. 1 uses bold lineson buses 24 and chipset 34 to depict an example of such a secure channelas established between processing unit 30 and TPM 44 according to theprocess of FIG. 5. That process begins after AACM 60 with E3PK 72A hasbeen stored in ROM 42, possibly according to a process such as the onedescribed above.

In particular, the process of FIG. 5 may begin in response to processingsystem 20 being powered on or reset, which may cause microcode inprocessing unit 30 to examine a predetermined location in ROM 42 todetermine whether ROM 42 contains an AC module. If an AC module isfound, processing unit 30 may load the AC module into protected internalRAM within processing unit 30. The protected internal RAM to receive theAC module may be referred to as the authenticate code execution area(ACEA) 38.

For purposes of illustration, one may assume that processing unit 30finds AACM 60 in ROM 42. As indicated at block 220, processing unit 30may then determine whether AACM 60 is authentic, in accordance with theexcerpt above from the LTPA Specification. For instance, processing unit30 may (a) calculate a hash of certain portions of AACM 60, (b) use RSApublic key 76 to decrypt signature 78, and (c) compare the decryptedsignature with the hash to determine whether AACM 60 matches what theOEM originally signed with the corresponding RSA private key. Processingunit 30 may also verify RSA public key 76 against a predetermined listof valid public keys. For instance, processing unit may derive a hashvalue from RSA public key 76 and compare that value against a list ofvalid hash values in protected storage in processing system 20. If RSApublic key 76 verifies good, and the hash of AACM 60 matches thedecrypted RSA signature, processing unit 30 may conclude that AACM 60 isauthentic.

If processing unit 30 is unable to find an AC module, or if processingunit 30 finds an AC module but determines that it is not authentic,processing unit 30 may log an appropriate error message, as indicated atblock 240. Processing unit 30 may then check a configuration setting inprocessing system 20 to determine whether processing system 20 should beallowed to use a non-ACM boot process, as depicted at block 250. If anon-ACM boot is to be allowed, processing unit 30 may perform thenon-ACM boot as depicted at block 252. If non-ACM boot is not allowed,the process may end without processing system 20 booting.

Referring again to block 220, if processing unit 30 determines that AACM60 is authentic, processing unit 30 may then extract the E3PKs from AACM60, as shown at block 222. Processing unit 30 may temporarily store theE3PKs in one or more processor registers or other internal storage, forinstance.

Processing unit 32 then decrypts the E3PKs (e.g., E3PK 72A, E3PK′ 75A,E3PK″ 77A) and saves the results (e.g., 3PK 72, 3PK′ 75, 3PK″ 77) inprotected storage within processing unit 32, as shown at blocks 224 and226. In the embodiment of FIG. 1, that protected storage is implementedas one or more registers that (a) are only modifiable by privilegedcode; (b) cannot be read, written, or debugged by non-privileged code;and (c) cannot be accessed by ITPs. In this context, privileged code iscode that could be carried external to the processor, but that requiresspecial authentication before it is run by the processor, and that thenruns in the processor in a sanitized environment, such that theprivileged code execution cannot be observed or manipulated by maliciousparties. In an alternative embodiment, the processing system may waituntil a future time to decrypt the E3PKs that aren't needed forestablishing a secure channel with the TPM. In the embodiment of FIG. 1,processing unit 30 uses PUK 70 to decrypt the E3PKs.

As shown at block 228, processing unit 30 and TPM 44 may then use 3PK 72to create a session key (SK) 74 to be used for protecting communicationsbetween processing unit 30 and TPM 44. Processing unit 30 and TPM 44 maythen use SK 74 to create a protected channel, as shown at block 230.That protected channel may traverse multiple system buses 24 and zero ormore components of chipset 34. TPM 44 and processing unit 30 may thenuse SK 74 to encrypt communications, as indicated at block 232. Inalternative embodiments, multiple session keys may be used forprotecting communications between processing unit 30 and TPM 44.

The protected channel may be used, for instance, to load keys or otherprotected information from TPM 44 into processing unit 30. Likewise, theprotected channel may be used to send keys or other sensitiveinformation from processing unit 30 to TPM 44. The protected channelthus ensures that any viewer of the channel cannot determine thecontents of the communications, and protects against modification of thedata in transit. Furthermore, the process for initializing the channelmay authenticate the end-points to protect against unauthorized accessand against replay and TPM swap attacks.

As shown at block 260, processing system 20 may then determine whetherother components are to be authenticated in the preliminary phase of theboot process. If so, the process may pass through page connector A toFIG. 6.

FIG. 6 is a flowchart of a process for authenticating components ofprocessing system 20, according to an example embodiment of the presentinvention. When control flows to FIG. 6 through page connector A,processing system 20 may attempt to locate a firmware manifest orauthentication code, such as BIOS AC 51, as shown at block 310. If BIOSAC 51 is not found, processing unit 30 may log an error, as indicated atblock 350, and the process may end without completing the boot process.If BIOS AC 51 is found, processing unit 30 may use 3PK′ 75 to compute anHMAC for the current BIOS image, as indicated at block 312.

As shown at block 320, processing unit 30 may then compare BIOS AC 51with the current AC to determine whether BIOS 50 has been tampered with.If the HMACs do not match, processing unit 30 may log an error as shownat block 350, and the process may end. If they do match, the preliminaryboot code from AACM 60 may hand off control to the system firmware, asshown at block 322.

As shown at block 330, processing system 20 may then attempt to locate amanifest such as VMM AC 53 for VMM 52. If VMM AC 53 is not found,processing unit 30 may log an error, as indicated at block 350, and theprocess may end. However, if VMM AC 53 is found, processing unit 30 mayuse 3PK″ 77 to compute an HMAC for the current VMM image, as indicatedat block 332. As shown at block 340, processing unit 30 may then compareVMM AC 53 with the current AC to determine whether VMM 52 has beentampered with. If the HMACs do not match, processing unit 30 may log anerror as shown at block 350, and the process may end. If they do match,BIOS 50 may hand off control to VMM 52, as shown at block 344. The aboveoperations may be used when VMM 52 includes components that serve moreor less as an OS.

When OS 54 is distinct from VMM 52, processing system 20 may useoperations like those described above to locate a manifest (e.g., OS AC55) for OS 54, and to prevent OS 54 from executing if OS 54 has beentampered with.

In light of the principles and example embodiments described andillustrated herein, it will be recognized that the illustratedembodiments can be modified in arrangement and detail without departingfrom such principles. Also, the foregoing discussion has focused onparticular embodiments, but other configurations are contemplated. Inparticular, even though expressions such as “in one embodiment,” “inanother embodiment,” or the like are used herein, these phrases aremeant to generally reference embodiment possibilities, and are notintended to limit the invention to particular embodiment configurations.As used herein, these terms may reference the same or differentembodiments that are combinable into other embodiments.

Similarly, although example processes have been described with regard toparticular operations performed in a particular sequence, numerousmodifications could be applied to those processes to derive numerousalternative embodiments of the present invention. For example,alternative embodiments may include processes that use fewer than all ofthe disclosed operations, processes that use additional operations,processes that use the same operations in a different sequence, andprocesses in which the individual operations disclosed herein arecombined, subdivided, or otherwise altered.

Also, although certain operations are described as being performed orcontrolled by an OEM in an example embodiment, other types of entitiesmay perform or control operations in other embodiments, includingwithout limitation entities that perform platform configuration,software installation, information technology (IT) assistance, etc.Also, this disclosure refers to the use of keys for various operations.It should be understood such use includes direct and indirect use. Forinstance, if a first key is used to generate a second key, and then thesecond key is used in an operation, both keys should be considered tohave been used in the operation. The second key will have been useddirectly, and the first key will have been used indirectly.

Alternative embodiments of the invention also include machine accessiblemedia encoding instructions for performing the operations of theinvention. Such embodiments may also be referred to as program products.Such machine accessible media may include, without limitation, storagemedia such as floppy disks, hard disks, CD-ROMs, ROM, and RAM; and otherdetectable arrangements of particles manufactured or formed by a machineor device. Instructions may also be used in a distributed environment,and may be stored locally and/or remotely for access by single ormulti-processor machines.

It should also be understood that the hardware and software componentsdepicted herein represent functional elements that are reasonablyself-contained so that each can be designed, constructed, or updatedsubstantially independently of the others. In alternative embodiments,many of the components may be implemented as hardware, software, orcombinations of hardware and software for providing the functionalitydescribed and illustrated herein.

In view of the wide variety of useful permutations that may be readilyderived from the example embodiments described herein, this detaileddescription is intended to be illustrative only, and should not be takenas limiting the scope of the invention. What is claimed as theinvention, therefore, is all implementations that come within the scopeand spirit of the following claims and all equivalents to suchimplementations.

1. At least one machine readable medium comprising instructions thatwhen executed on a processing system cause the processing system toperform a method comprising: retrieving an encrypted version of acryptographic key from nonvolatile memory of the processing system to aprocessing unit of the processing system during a boot process;decrypting the cryptographic key in the processing unit; retrieving apredetermined authentication code for software of the processing system;using the cryptographic key to compute a current authentication code forthe software before executing any instructions from the software; anddetermining whether the software should be trusted, based at least inpart on a comparison of the predetermined authentication code with thecurrent authentication code.
 2. The at least one medium of claim 1,wherein the operation of decrypting the cryptographic key in theprocessing unit comprises: using a key stored in nonvolatile storage inthe processing unit to decrypt the encrypted version of thecryptographic key.
 3. The at least one medium of claim 1, wherein theoperation of retrieving the encrypted version of the cryptographic keyfrom nonvolatile memory comprises: retrieving the encrypted version ofthe cryptographic key from a component other than a trusted platformmodule (TPM).
 4. The at least one medium of claim 1, wherein theoperation of using the cryptographic key to compute a currentauthentication code for the software comprises: using the cryptographickey to compute a current hashed message authentication code (HMAC) forthe software.
 5. The at least one medium of claim 1, wherein theoperation of using the cryptographic key to compute a currentauthentication code for the software comprises: using a key based on thecryptographic key to compute a current hashed message authenticationcode (HMAC) for the software.
 6. The at least one medium of claim 1,wherein the software to be authenticated comprises boot firmware.
 7. Atleast one machine readable medium comprising preliminary bootinstructions that when executed on a processing system cause theprocessing system to perform a method comprising: during a boot process,a processing unit of the processing system using a cryptographicprocessing unit key (PUK), stored in nonvolatile memory of theprocessing unit, to decrypt an encrypted version of an authenticationkey; and during the boot process, the processing unit using theauthentication key to authenticate a candidate code module beforeexecuting any instructions from the candidate code module.
 8. The atleast one medium of claim 7, the method comprising the processing unitauthenticating (a) a boot firmware image before executing anyinstructions from the boot firmware image, (b) at least part of avirtual machine monitor (VMM) before executing any instructions from theVMM, and (c) at least part of an operating system (OS) before executingany instructions from the OS.
 9. The at least one medium of claim 7, themethod comprising authenticating a boot firmware image before executingany instructions from the boot firmware image, wherein (a) theprocessing unit is configured to serve as a bootstrap processor, (b) theat least one machine readable medium is configured to serve asnon-volatile boot storage for the bootstrap processor, (c) the bootstrapprocessor is to be coupled to the non-volatile boot storage via a bus,and (d) the bootstrap processor, non-volatile boot storage, and bus areall to be included in a local processing system.
 10. A processing systemcomprising: a processing unit with nonvolatile storage; a cryptographicprocessing unit key (P UK) stored in the nonvolatile storage; at leastone nonvolatile storage component in communication with the processingunit; a candidate code module in the at least one nonvolatile storagecomponent; and an augmented boot code module in the at least onenonvolatile storage component; the processing unit configured to executecode from the augmented boot code module before executing code from thecandidate code module; and wherein the augmented boot code modulecomprises: an encrypted version of an authentication key; andinstructions which, when executed by the processing unit, cause theprocessing unit to perform operations comprising: using the PUK todecrypt the encrypted version of an authentication key; and using theauthentication key to authenticate the candidate code module beforeexecuting any instructions from the candidate code module.
 11. Aprocessing system according to claim 10, wherein: the at least onenonvolatile storage component comprises nonvolatile memory; and thecandidate code module comprises a boot firmware image.
 12. A processingsystem according to claim 10, wherein: the candidate code modulecomprises at least part of a virtual machine monitor.
 13. A processingsystem according to claim 10, wherein: the at least one nonvolatilestorage component comprises nonvolatile memory and a mass storagedevice; and the candidate code module resides in the mass storagedevice.
 14. A processing system according to claim 13, wherein: theaugmented boot code module resides in the nonvolatile memory.
 15. Aprocessing system according to claim 10, wherein the operation of usingthe authentication key to authenticate the candidate code modulecomprises: using a key based at least in part on the authentication keyto authenticate the candidate code module.
 16. A processing systemaccording to claim 10, wherein (a) the PUK is permanently burned intothe processing unit, (b) the processing unit couples to the at least onenonvolatile storage component via a bus, and (c) the processing unit,the at least one nonvolatile storage, and the bus are all included in alocal processing system but are not all located on a single integratedcircuit.
 17. An apparatus comprising: a non-transitorymachine-accessible medium; and an augmented boot code module in themachine-accessible medium, wherein the augmented boot code modulecomprises: an encrypted version of an authentication key; andpreliminary boot instructions to be executed during a boot process by aprocessing unit with nonvolatile storage and a cryptographic processingunit key (PUK) stored in the nonvolatile storage; the preliminary bootinstructions comprising instructions which, when executed by theprocessing unit, cause the processing unit to perform operationscomprising: using the PUK to decrypt the encrypted version of theauthentication key; and using the authentication key to authenticate acandidate code module before executing any instructions from thecandidate code module.
 18. An apparatus according to claim 17, whereinthe instructions, when executed, cause the processing unit toauthenticate a boot firmware image before executing any instructionsfrom the boot firmware image.
 19. An apparatus according to claim 17,wherein the instructions, when executed, cause the processing unit toauthenticate at least part of a virtual machine monitor (VMM) beforeexecuting any instructions from the VMM.
 20. An apparatus according toclaim 17, wherein the instructions, when executed, cause the processingunit to authenticate at least part of an operating system (OS) beforeexecuting any instructions from the OS.
 21. An apparatus according toclaim 17, wherein the instructions, when executed, cause the processingunit to authenticate a candidate code module residing in nonvolatilememory.
 22. An apparatus according to claim 17, wherein theinstructions, when executed, cause the processing unit to authenticate acandidate code module residing in a mass storage device.
 23. Anapparatus according to claim 17, wherein the operation of using theauthentication key to authenticate the candidate code module comprises:using a key based at least in part on the authentication key toauthenticate the candidate code module.
 24. An apparatus according toclaim 17, wherein (a) the instructions, when executed, cause theprocessing unit to authenticate a boot firmware image before executingany instructions from the boot firmware image, (b) the processing unitis configured to serve as a bootstrap processor, (c) themachine-accessible medium is configured to serve as non-volatile bootstorage for the bootstrap processor, (d) the bootstrap processor iscoupled to the non-volatile boot storage via a bus, and (e) thebootstrap processor, non-volatile boot storage, and bus are all includedin a local processing system.